Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-190 < prev next >

Wrap

Text File | 1988-12-01 | 29KB | 805 lines

INDRA Working Paper INDRA Note 1114 IEN 190 9th. July 1981 Routing and Access Control in UK to US Services Robert Cole and Robert Braden ABSTRACT: The routing and access control problems for US-UK Catenet operations are discussed and an interim solution proposed, based on addressing mechanisms. Given the present generation of internet gateways, it is necessary to curtail the use of the full physical connectivity between the US and the UK to avoid gateway routing problems and undesirable paths. Department of Computer Science University College, London Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 C O N T E N T S 1. Introduction...........................................2 2. Background.............................................2 3. Network Connectivity...................................3 4. How it Will Work.......................................5 5. Access Control for the PTT Network Connections.........6 6. Reconfiguring for Failure..............................9 7. Issues in Internetworking.............................11 8. Conclusion............................................12 - 1 - [Cole and Braden] 1. Introduction The removal of the TIP at UCL, and the consequent change to TCP-based service from UCL to the DARPA Catenet, present some interesting problems in routing and access control. These problems are discussed here, and some interim (and ad hoc) solutions are presented. The changes in connectivity at UCL, and at RSRE, mean that the extension of the DARPA Catenet into the UK must be considered as a whole; hence this document also looks at the position of the RSRE network (PPSN) in the routing schemes. 2. Background When UCL moves over to an entirely TCP-based access to the Catenet, all of our traffic will be routed via a number of gateways. As most of the traffic will be destined for the ARPANET at least two gateways will be involved. UK users of hosts on the ARPANET can be divided into two groups: 1. Authorised MoD users -- this includes RSRE and UCL experimental traffic. 2. All other users The MoD authorised users are allowed to use SATNET as a path for their traffic into the ARPANET. The others must use a PTT-supplied path to cross the Atlantic and enter the ARPANET through a special gateway. The configurations and services UCL are putting forward for all users is presented in [1]. Essentially, MoD users may gain access to ARPANET via: a. PPSN b. TAC (dial-in terminals) c. PAD to PSS and UCL d. FTP via PSS and UCL Other users will access ARPANET via: a. PAD to UCL (via PSS or SRCNET) b. FTP to UCL (via PSS or SRCNET) From UCL, access control is applied for each user and the appropriate path is selected. - 2 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 This note describes how the paths are enforced, both for forward and return traffic, and how a number of routing problems from dual connectivity are avoided. 3. Network Connectivity The physical connections available between UK systems and the US are shown in figure 1. Note: i. Gateways are indicated by the letter "G". ii. That a single gateway has been assumed at PPSN for simplicity. iii. A single gateway (G') has been shown at UCL. When line 77 is removed, and until the C/70 gateway is installed, this gateway will be implemented by two smaller gateways having only 2 and 3 ports. The exact configuration is yet to be decided. The "PTT network path" includes the concatenated VAN/PTT networks TELENET and TYMNET in the US, IPSS across the Atlantic, and PSS and SRCNET in the UK. These networks all use X.25, and are joined by X.75 gateways which are not shown here. The gateway which is shown between the ARPANET and the VAN network TELENET is being built by BBN and is therefore know as the "BBN VAN gateway"; it will be sited in the US. Across the PTT network path, internet datagrams are encapsulated within X.25 packets, over virtual calls which are opened as required by the BBN VAN gateway or by UCL. We use the term "tunnel" for such a path using X.25 encapsulation of IP datagrams. A second tunnel is shown, linking UCL with PPSN within the UK, using the British Telecom network PSS. - 3 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 PTT network path G ____________________________________________ / | | / | | / | ___________ | / |---| SRC-PSS | | _________ | ----------- | | | | | | ARPA | __________ PSS Tunnel / | NET | | UCLNET |--------------| / | | ---------- | / --------- | | / \ __________ | | / ________ G --| SATNET | -- G' ---------------- G -| PPSN | ---------- | ________ -------- |___| C/30 | | TAC | -------- Figure 1. Physical Connections For UK-US Access The physical connectivity shown in figure 1 presents several serious problems for internet routing algorithms. The present generation of IP gateways [2] assumes all paths between gateways are equivalent in delay, cost, and administrative authorisation. The various paths shown in figure 1 include violations of all three of these conditions. For example, routing MoD or ARPANET traffic over the PTT path, hence over IPSS, between the US and UK will create unacceptable costs. As an interim solution, we propose to effectively reduce the connectivity, to that shown in Figure 2 [1]. The upper (PTT) path provides ARPANET access for non-MoD users, while the lower (SATNET) path is for MoD use. - 4 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 PTT path _____________ G -----------------------| SRC-PSS | / (IPSS tunnel) ------------- _________ | | | ARPA | __________ (PSS tunnel) | NET | | UCLNET |--------------| | | ---------- | --------- | | \ __________ | | ________ G --| SATNET | -- G' ----------------G-| PPSN | ---------- | ________ -------- |___| C/30 | | TAC | -------- Figure 2. Apparent Connectivity For Service 4. How it Will Work The reduction in connectivity between the available physical connections and the apparent connections is achieved by using addresses to convince the ARPANET gateways they are connected to logically disjoint networks. We also use addressing to ensure that US hosts use the correct path for return traffic. This is achieved by using different network numbers on each path, enabling the US hosts to select different gateways. Thus, we will represent all non-MoD users as coming from a network we will call SRC-PSS, and all other users as coming from UCLNET. Of course traffic from PPSN is not affected. In this way the US hosts will select the ARPANET-SATNET gateway (and thus the SATNET path) for MoD authorised users and the BBN VAN gateway for all others. We can summarise the paths from the UK to the US as: 1. From PPSN: this traffic has a direct link to the SATNET gateway, and only allows authorised traffic 2. From PSS: this traffic must pass through access control at UCL and thus the correct path is chosen 3. From TAC: this traffic has direct access to SATNET, but only authorised users will know the telephone number. Eventually TIP (TAC) login will increase the security. - 5 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 We can summarise the US to UK access (including UK-US return traffic) as a sequence of steps: 1. The US host will choose a gateway based on the destination network number. For MoD authorised users and all US users addressing PPSN and UCL networks, this will be the ARPANET-SATNET gateway. For all other users the BBN VAN gateway should be chosen. 2. Traffic arriving via the VAN gateway and IPSS will enter a UCL service host and be forwarded into PSS and SRCNET or to a local UCL host as required. The UCL service host will provide higher-level gateways which match the differing protocols in the DARPA Catenet and X.25 domains: a transport-service gateway for FTP traffic and a terminal protocol converter for terminal traffic. 3. Traffic arriving from the UCL-SATNET gateway will pass to either the TAC, PPSN gateway, or into the UCL network via the SATNET Access Machine (SAM) [3]. 5. Access Control for the PTT Network Connections Extensive use is made of the PTT networks for carrying user traffic and encapsulated datagrams. Controls are required to ensure that only authorised users are allowed to connect to the various entry points of the Catenet. There are two areas to be considered: user level access, and gateway access for encapsulated IP datagrams (tunnels). 1. All user level access to the Catenet from PSS and SRCNET is controlled at UCL by a login procedure, both for terminal access and file transfer. This is discussed in [1]. Similarly, any PSS access to PPSN will be vetted by the MoD's VAN gateway. 2. A more serious problem is the misuse of the tunnels across the PTT networks, for two reasons. First, one or both ends of a tunnel may need to treat the opposite end as a "trusted host" with respect to application of access controls. Since the two ends of the tunnel are connected with switched rather than permanent circuits, one must guard against a third host masquerading as one of the legitimate tunnel hosts. Secondly, the virtual X.25 calls used to carry IP traffic will incur usage charges. Across the international link IPSS, in particular, these charges will be substantial. - 6 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 Figure 1 shows the two tunnels that are planned. 1. From UCL to BBN VAN gateway via IPSS. (Prior to providing service, we will start accessing IPSS via PSS.) 2. From UCL to PPSN via PSS The "trusted host" problem can be handled easily, by having each end of the tunnel accept calls only from the expected host at the other end. Since the PTT network provides the remote host address, this tunnel can only be misused by "breaking" the PTT network. For example, the UCL end of the "PSS tunnel" will accept X.25 virtual calls only from the PPSN gateway, while the MoD VAN gateway to PPSN will accept X.25 virtual calls only from specified calling addresses. Similarly, UCL will only accept calls from the BBN VAN gateway, and the latter will have a list of acceptable calling addresses [4]. Usage charges can pose much greater difficulty. i. Accounting The IP tunnels and the VAN gateway [3] will operate only on IP datagrams, and therefore can account for usage only on the basis of addressing that is visible at that level of protocol. Thus, it is possible to account by internet host, but not by virtual call or even individual user. This forces any user-level accounting and access control back onto the hosts at each end of the virtual call, and at present no ARPANET hosts are prepared to accept this responsibility. Haverty [3] has pointed out a further problem with host-level accounting: the internet gateways do not ensure correct source addresses in the internet datagrams they process. Thus, the VAN gateway cannot rely upon even the alleged internet source host of a datagram destined for the tunnel. ii. GGP It is very undesirable to have internet gateways on both ends of a tunnel through a PTT network, since GGP messages interchanged by the gateways will generate excessive usage charges. Thus, in Figure 2 - 7 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 the UCL end of the IP tunnel must be an internet host, not a gateway. The PSS tunnel for PPSN cannot avoid this GGP traffic, but this path is expected to be used only for experiments in alternate routing, and will not normally exist. iii. Retransmission There are serious problems with the use of an end- to-end retransmission protocol like TCP across an IP tunnel. Some host implementations of TCP use retransmission timeout computations that are incapable of adapting to long network delays, causing execessive retransmissions when calling the UK. The result will be to create excessive usage charges which are not under user control. iv. Call Multiplexing To minimise usage costs, it is necessary to use the X.25 virtual call as efficiently as possible. In general, there should be at most one virtual call open for a given tunnel. When traffic ceases, this call should be closed after a suitable interval. The minimum call duration charge interval should be considered when choosing this idle-call timeout interval. If both ends of the tunnel open calls to each other simultaneously, two calls will result, and one must be closed. There can be an agreement between the two ends of the tunnel that one of them will always close a duplicate call. In the absence of such an agreement, a symmetric algorithm must be used to resolve the race. For example, each side can accept the incoming call and process traffic from it, wait for a random interval, and then close the incoming call (unless the other side has meanwhile closed the other outgoing call). In the event that both sides wait the same time and therefore close their calls simultaneously, the algorithm should be repeated. - 8 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 6. Reconfiguring for Failure The weak links in the routing seen by the Catenet gateways are the Atlantic connections. When one of these breaks, whole sections of the UK user population will be disconnected. In fact, the physical connectivity allows us to realign all UK-US traffic onto the single remaining path, and in theory this change is fairly easily made. In practice, the cost of using the PTT path and the politics of using the SATNET path may preclude such operations. However, we wish to understand the technical problems in switching from the normal dual path to either single path. 1. SATNET failure The MoD traffic via UCL may be routed via IPSS quite easily. PPSN may open their own virtual call to the BBN VAN gateway, but they would need to indicate themselves as neighbours to obtain traffic from the US side (this requires another null network). If a gateway at UCL made itself known as a neighbour to the BBN VAN gateway, a similar path would exist. In either case, traffic from the TAC would be catered for. See figure 3. Notice that the "PTT network path" in Figure 3 really constitutes two or three different internet networks -- SRC-PSS, UCLNET, and perhaps PPSN. For this to work, we require BBN's VAN gateway to support a number of different "local" networks on the VAN side. We believe this to be feasible within the general framework described in [4]. - 9 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 PTT network path (IPSS tunnels) G ________________________________________ / | | / | | / | ___________ | / |---| SRC-PSS | | _________ | ----------- | | | | | | ARPA | ______|___ PSS tunnel | | NET | | UCLNET |---------------| / | | ---------- | / --------- | | / | | / __________ | |/ ________ | SATNET | G' --------------- G -| PPSN | ---------- | ________ -------- |___| C/30 | | TAC | -------- Figure 3. Alternative paths for SATNET route failure 2. IPSS failure The non-MoD traffic could be switched by making it appear to come from UCLNET, however all existing connections would be lost as the addresses change. To continue using the PSS-SRC network addresses via SATNET would require UCL to impose a gateway and inform the UCL-SATNET gateway of the new neighbour. The dynamic rearrangement of Atlantic links requires the gateways to issue redirect message and the US hosts to act on them. See figure 4. ___________ G ------| SRC-PSS | | ----------- _________ | | | | | ARPA | _____|____ PSS tunnel | net | | UCLNET |-----------| | | ---------- | --------- | | \ __________ | | ________ G --| SATNET | -- G' ------------ G -| PPSN | ---------- | ________ -------- |___| C/30 | | TAC | -------- Figure 4. Alternative paths for IPSS route failure - 10 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 7. Issues in Internetworking The problems, and solutions, discussed above represent specific cases of more general issues in Catenet design and operation. In [5] [6] [7] Rosen presents a number of problems in the current Catenet design and implementation. He then goes on to propose a new model for catenet operation. This section will look at the UCL problems in this context, as a contribution to the debate. The addressing solution used at UCL to force a particular route on a packet has 3 disadvantages. 1. It reduces the potentially rich connectivity of the available physical connections to a minimum. 2. It manipulates Catenet routing in an unacceptable way (i.e. a hack). 3. It requires complicated manoevres to restore service via alternative paths when the minimum connectivity is further reduced by failures. It is not clear how easy it will be to automate any switchover. Ideally, the Catenet routing algorithms, implemented in the gateways, should be capable of knowing the full UK-US connectivity without the UK being used as an expressway for US-US traffic. In the present Catenet design and with the present Catenet protocols, such full knowledge by the gateways would have to be constrained by specifying source and return routes in each IP datagram. In practice we find that dependence upon source routing is impractical, as it requires every gateway, and every US host that any UK user may access, to support these 'options'. The overhead of this option on IPSS/PSS charges is another concern. Even more seriously, source routing would move the burden of reconfiguration back onto the hosts and, in the end, the users. In the model put forward by Rosen, gateway routing may be constrained by factors such as cost and suitability of paths. In the UCL case we should also add political factors arising from crossing national boundaries and Telecommunications monopolies. In the Rosen model the full UK-US connectivity would be available to the Switches. Thus we must look at some mechanisms by which we can constrain the actual routes available to particular classes of traffic. The obvious mechanism is to use a 'class field' in the packet which identifies a potential routing problem to the - 11 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 switches. However the UK is not alone in its problems, and in a general Catenet we can imagine a large number of paths having a number of user classes giving a very large class- problem space. Of course, if the entire Catenet is to be accessible from everywhere, each class/path combination must have a unique representation to enable the source Switch to plan a route. The situation is further complicated by allowing a gradation of class. It is not unreasonable to suppose that someone may be prepared to pay for a path (such as IPSS) if the first choice (say SATNET) is unable to provide the required level of service due to traffic loading or malfunction. Thus we also need a mechanism that can say 'if the delay on path X goes above d then use alternative path Y'. Similarly we may have a situation where an administration will say 'allow any users of class m on this path as long as the loading is less than n%'. All of this complexity for each packet! We admit this is an argument about the distant future; however we should consider these general problems now because we already have specific instances of them. As a final note, it is worth pointing out that the UCL addressing hack works because all UK-US traffic to the DARPA Catenet comes through UCL. This situation may not continue. It is not infeasible that a UK research establishment or a US Defense installation in the UK (or Europe) may obtain independent access to the Catenet. Or, the German SATNET installation might decide to increase their service reliability by adding extra connectivity. Each of these may use existing paths as alternatives. In these cases our addressing solution may fall apart, with disastrous results. 8. Conclusion The routing and access control problems for US-UK Catenet operations have been discussed and an interim solution proposed, based on addressing mechanisms. Given the present generation of internet gateways, it is necessary to curtail the use of the full physical connectivity between the US and the UK to avoid gateway routing problems and undesirable paths. Access control between the PTT networks and the DARPA Catenet has also been covered in some detail. - 12 - [Cole and Braden] Routing and Access Control Indra Note 1114 in UK-US Services IEN 190 References 1. Higginson, P. and Braden, R., UK-US Services, Indra Note 1101, IEN 185 2. Strazisar, G, How to Build a Gateway, IEN 109 3. Cole, R. and Lloyd, P., The SATNET Access Machine, Indra Note 1113 4. Haverty, J., Van Gateway: Some Routing and Performance Issues, IEN 181 5. Rosen, E, Issues in Internetting Part 1: Modelling the Internet, IEN 184 6. Rosen, E, Issues in Internetting Part 2: Accessing the Internet, IEN 187 7. Rosen, E, Issues in Internetting Part 3: Addressing, IEN 188 - 13 - [Cole and Braden]